• 专利附录
  • 专利说明
  • 权利要求
  • 类似技术
  • 同族专利
  • 引用文献
  • 法律状态
  • 优先权
    • 专利摘要:
    Embodiments of the present invention include setting, via a first consensus node, a timer that runs out before a timeout of a display change; sending, to a second consensus node, a request for one or more consensus messages that the first consensus node is missing in response to the timer running out; receiving, from the second consensus node, one or more consensus messages, each digitally signed by a private key from a corresponding consensus node, which generates the respective one or more consensus messages; and determine that a block of transactions is valid, if the number of compromise messages included in the one or more received consensus messages is greater than or equal to 2f + 1, where f is a maximum number of bad nodes that is tolerable by the protocol of confidence based on Byzantine fault tolerance.
    公开号:BR112019008172B1
    申请号:R112019008172-0
    申请日:2018-11-07
    公开日:2022-01-25
    发明作者:Dayi Yang
    申请人:Advanced New Technologies Co., Ltd；
    IPC主号:
    专利说明:

    FIELD OF THE INVENTION
    [001] The present invention relates to a computer-implemented method for facilitating a consensus process in a trusted protocol network based on Practical Byzantine Fault Tolerance (PBFT), a non-transient, computer-readable storage medium and to a system. BACKGROUND OF THE INVENTION
    [002] Trust protocol networks, which may also be referred to as blockchain systems, consensus networks, distributed ledger system (DLS) networks, or trust protocol, allow participating entities to store data securely and immutably. A trust protocol can be described as a record of transactions, and multiple copies of the trust protocols are stored across the trust protocol network. Examples of types of trust protocols can include public trust protocols, consortium trust protocols, and private trust protocols. The public trust protocol is open to all entities to use the trust protocol, and participate in the consensus process. A private DLS is provided for a specific entity, which centrally controls read and write permissions.
    [003] Another type of trust protocol system includes a consortium trust protocol system. A consortium trust protocol system is provided for a select group of entities, which control the consensus process and include an access control layer. Consequently, one or more entities participating in the consortium trust protocol system have control over who can access the consortium trust protocol system and who can participate in the consortium trust protocol system consensus process. For example, a group of companies (eg companies, academic institutions) may participate in a consortium trust protocol system to record data in an immutable way (eg transactions). In some examples, an entity may be able to access/view data within the consortium trust protocol system, but not contribute data to the consortium trust protocol system.
    [004] A trust protocol includes a series of blocks, each of which contains one or more transactions performed on the network. Each block can be converted into a page of the record, while the trust protocol itself is a complete copy of the record. Individual transactions are confirmed and added to a block, which is added to the trust protocol. Copies of the trust protocol are replicated across the network nodes. In this way, there is a network-wide consensus on the status of the trust protocol.
    [005] Fault tolerance is a concern in trusted protocol systems. Fault tolerance can generally be described as a network's tolerance of nodes that fail or act maliciously. Fault tolerance is of particular concern in trust protocol systems that have fewer participating nodes, such as consortium trust protocol systems. Byzantine Fault Tolerance (BFT) can be described as the reliability of a fault-tolerant distributed computing system, such as a trusted protocol system. BFT describes reliability, in cases where components can fail and/or are malicious, and there is imperfect information about whether a component has failed or is malicious. BFT is leveraged in consensus protocols to allow systems to reach consensus despite malicious system nodes propagating incorrect information to other peers. The purpose of BFT is to defend against system failures by mitigating the influence that malicious nodes have on the correct functioning of the consensus protocol. Practical BFT (PBFT) is an optimization of BFT. PBFT works on asynchronous systems, as a consortium trust protocol system, and assumes that there are independent node failures and manipulated messages propagated by specific independent nodes. In PBFT, all nodes in a consensus system are ordered in a sequence, with one node being a primary node (different nodes being designated as the primary node over time) and the other nodes being backup nodes. All nodes communicate with each other through broadcast messages and so-called honest nodes reach consensus through a majority.
    [006] In PBFT, consensus security can ensure that two nodes that do not have problems associated with them do not come to a consensus with different values. Consensus liveliness can ensure that nodes do not fall into infinite loops while exchanging messages, and nodes can come to their final state.
    [007] In some cases, the consensus nodes in a consortium trust protocol may be very distant geographically, and network quality or connectivity cannot be guaranteed. In such cases, broadcast messages may not reach all consensus nodes, which affects the consensus nodes' ability to reach PBFT consensus. As a result, collecting enough responses to reach consensus can be time-consuming and computationally expensive. DESCRIPTION OF THE INVENTION
    [008] Embodiments of the present invention are directed to facilitate the synchronization and consensus processes of a trusted protocol network based on the practice of Byzantine Fault Tolerance (PBFT). More particularly, embodiments of the present invention are directed to facilitating consensus message transmissions and node synchronization in a PBFT-based trust protocol network using a gossip-based communications method, and adding digital signatures to consensus messages. .
    [009] In some embodiments, actions include setting, via a first consensus node, a timer that runs out before a timeout of a display change; sending, to a second consensus node, a request for one or more missing consensus messages via the first consensus node in response to the timer running out; receiving, from the second consensus node, one or more consensus messages, each digitally signed by a private key from a corresponding consensus node, which generates the respective one or more consensus messages; and determine that a block of transactions is valid, if the number of compromise messages included in the one or more received consensus messages is greater than or equal to 2f + 1, where f is a maximum number of bad nodes that is tolerable by the protocol of confidence based on practical Byzantine fault tolerance. Other embodiments include corresponding computer systems, apparatus and programs configured to perform the actions of the methods encoded in computer storage devices.
    [0010] These and other embodiments may optionally include one or more of the following features: the request includes a sequence number that indicates a consensus round number; the one or more consensus messages include one or more pre-prepared messages, prepared messages, and compromise messages missed by the first consensus node; one or more consensus messages are stored on one or more consensus nodes on which they are generated or stored, until a stable checkpoint is reached; receiving one or more sequence numbers corresponding to one or more consensus messages, wherein each sequence number indicates a number of a consensus round associated with a corresponding consensus message; send the transaction block to a trusted protocol and state database, if the transaction block is determined to be valid; sending, to a third consensus node, a request for a second one or more missing consensus messages via the second consensus node in response to the timer running out and if the transaction block is determined to be invalid; receiving, from the third consensus node, the second one or more consensus messages, each digitally signed by a private key from a corresponding consensus node, which generates the second one or more consensus messages; and determining that the transaction block is valid, if the number of commitment messages included in one or more consensus messages and the second one or more consensus messages is greater than or equal to 2f + 1.
    [0011] The present invention also provides one or more non-transient computer-readable storage media coupled to one or more processors and having instructions stored therein which, when executed by one or more processors, cause the one or more processors to perform operations in accordance with embodiments of the methods provided herein.
    [0012] The present invention further provides a system for implementing the methods provided herein. The system includes one or more processors, and a computer-readable storage medium coupled to the one or more processors having instructions stored therein which, when executed by the one or more processors, cause the one or more processors to perform operations in accordance with of carrying out the methods provided herein.
    [0013] It is understood that the methods according to the present invention may include any combination of the aspects and features described herein. That is, the methods according to the present invention are not limited to the combinations of features and features specifically described herein, but also include any combination of the features and features provided.
    [0014] Details of one or more embodiments of the present invention are presented in the accompanying drawings and in the description below. Other features and advantages of the present invention will be apparent from the description and drawings, and from the claims. BRIEF DESCRIPTION OF THE DRAWINGS
    [0015] Figure 1 illustrates an example environment that can be used to carry out embodiments of the present invention.
    [0016] Figure 2 illustrates an example of conceptual architecture according to the embodiments of the present invention.
    [0017] Figure 3 illustrates an example of consensus process based on PBFT according to embodiments of the present invention.
    [0018] Figure 4 illustrates an example structure of a PBFT-based consensus message according to embodiments of the present invention.
    [0019] Figure 5 illustrates an example process that can be performed according to the embodiments of the present invention.
    [0020] Similar reference symbols in the various drawings indicate similar elements. DESCRIPTION OF EMBODIMENTS OF THE INVENTION
    [0021] Embodiments of the present invention are intended to facilitate the synchronization and consensus processes of a trusted protocol network based on practical Byzantine fault tolerance (PBFT). More particularly, embodiments of the present invention are directed to facilitating consensus message transmissions and node synchronization in a PBFT-based trust protocol network using a gossip-based communications method, and adding digital signatures to consensus messages. . In this way, and as described in more detail here, communication bandwidth consumption can be reduced, and system reliability can be improved. In some embodiments, actions include setting, via a first consensus node, a timer that runs out before a display change times out; sending, to a second consensus node, a request for one or more missing consensus messages via the first consensus node in response to the timer running out; receiving, from the second consensus node, one or more consensus messages, each digitally signed by a private key from a corresponding consensus node, which generates the respective one or more consensus messages; and determine that a block of transactions is valid, if the number of compromise messages included in the one or more received consensus messages is greater than or equal to 2f + 1, where f is a maximum number of bad nodes that is tolerable by the protocol of confidence based on practical Byzantine fault tolerance.
    [0022] To further provide context for embodiments of the present description, and as introduced above, trust protocol networks, which may also be referred to as consensus networks (e.g. composed of peer-to-peer nodes), Distributed accounting system, or simply trust protocol, allows participating entities to conduct transactions and store data in a secure and immutable manner. A trust protocol can be provided as a public trust protocol, a private trust protocol, or a consortium trust protocol. Embodiments of the present invention are described in greater detail herein with reference to a consortium trust protocol, wherein the consensus process is controlled by a pre-selected set of nodes. It is contemplated, however, that embodiments of the present invention may be carried out in any appropriate type of trusted protocol.
    [0023] In a consortium trust protocol, the consensus process is controlled by an authorized set of nodes, one or more nodes being operated by a respective entity (eg a company). For example, a consortium of ten (10) entities (eg companies) may operate a consortium trust protocol system, each of which operates at least one node in the DLS consortium. Thus, the consortium trust protocol system can be considered a private network in relation to the participating entities. In some examples, each entity (node) must sign all blocks for the block to be valid and added to the trust protocol. In some examples, at least a subset of entities (nodes) (eg at least (7) entities) must sign all blocks for the block to be valid and added to the trust protocol. An example of a consortium trust protocol system includes Quorum, developed by JP Morgan Chase & Co. of New York, New York. Quorum can be described as an authoritative, enterprise-focused trust protocol infrastructure designed specifically for financial use cases. Quorum is built on Go Ethereum, the code base of the Ethereum trust protocol, which is provided by the Ethereum Foundation of Zug, Switzerland.
    [0024] In general, a consortium trust protocol system supports transactions between entities participating, with permission, in the consortium trust protocol system. A transaction is shared with all nodes within the consortium trust protocol system, because the trust protocol is replicated on all nodes. That is, all nodes are in a perfect state of consensus regarding the trust protocol. To reach consensus (for example, agree to add a block to a trust protocol), a consensus protocol is implemented within the consortium trust protocol network. An example of a consensus protocol includes, without limitation, proof of work (POW) implemented on the Bitcoin network.
    [0025] Embodiments of the present invention include computer-implemented methods to facilitate consensus processes of a PBFT-based trusted protocol network. More particularly, embodiments of the present invention are directed to facilitating node synchronization and consensus message transmissions in a PBFT-based trust protocol network using a gossip-based communications method, and adding digital signatures to messages of consensus. In this way, and as described in more detail here, communication bandwidth consumption can be reduced, and system reliability can be improved.
    [0026] In accordance with embodiments of the present invention, the consensus nodes of a consortium trust protocol system execute a PBFT consensus protocol. In some examples, nodes can send consensus messages. In accordance with embodiments of the present invention, examples of consensus messages may include, without limitation, prep, prepare, and confirm. In some embodiments, a digital signature and sequence number are included in each consensus message. The digital signature can be used to identify the node that sent the respective consensus message, and the sequence number indicates a consensus round, within which the consensus message was sent.
    [0027] Each consensus node can store or log all received consensus messages. If a consensus node (e.g. backup node) of the trust protocol network is recovered from a disconnect, and had lost one or more consensus messages, it can synchronize with other nodes looking for lost messages from one or more other nodes of the consensus. In accordance with embodiments of the present invention, consensus messages can be obtained using a gossip algorithm, as opposed to, for example, transmitting a search request to the entire trust protocol network. As consensus messages fetched from another consensus node are digitally signed by the respective consensus node, the source of the fetched consensus message can be confirmed (and trusted). In some examples, the backup node might be able to fetch all lost messages in a single sync. As such, the synchronization complexity, or consensus, can be reduced to O(1) under ideal conditions, compared to standard PBFT-based O(n) multicasting.
    [0028] Figure 1 represents an example environment (100) that can be used to carry out embodiments of the present invention. In some examples, the example environment (100) allows entities to participate in a consortium trust protocol system (102). The example environment (100) includes computing systems (106, 108) and a network (110). In some examples, network (110) includes a local area network (LAN), wide area network (WAN), the Internet, or a combination thereof, and connects web sites, user devices (e.g., computing devices ) and backend system. In some examples, the network (110) may be accessed via a wired and/or wireless communication link.
    [0029] In the example described, the computing systems (106, 108) may include any appropriate computing system that allows participation as a node in the consortium trust protocol system (102), to store transactions in a trust protocol (104). Examples of computing devices (120) include, without limitation, a server, a desktop computer, a laptop computer, a tablet computer device, and a smartphone. In some examples, the computer systems (106, 108) host one or more computer-implemented services to interact with the consortium trust protocol system (102). For example, the computer system (106) may host computer-implemented services of a first entity (e.g., user A), such as a transaction management system that the first entity uses to manage its transactions with one or more entities ( e.g. other users). The computer system (108) may host computer-implemented services of a second entity (e.g. user B), such as a transaction management system that the second entity uses to manage its transactions with one or more other entities (e.g. , other users). In the example of Figure 1, the consortium trust protocol system (102) is represented as a peer-to-peer network of nodes, and the computing systems (106, 108) provide first entity and second entity nodes, respectively. , which participate in the consortium trust protocol system (102).
    [0030] Figure 2 illustrates an example of conceptual architecture (200) according to embodiments of the present invention. The conceptual architecture (200) includes an entity layer (202), a hosted services layer (204), and a trust protocol layer (206). In the example shown, the entity layer (202) includes three entities, Entity_1 (E1), Entity_2 (E2) and Entity_3 (E3), each entity having a respective transaction management system (208).
    [0031] In the illustrated example, the hosted services layer (204) includes trusted protocol interfaces (210) for each transaction management system (208). In some examples, a respective transaction management system (208) communicates with a respective trusted protocol interface (210) over a network (e.g., the network (110) of Figure 1) using a communication protocol (e.g. example, secure hypertext transfer protocol (HTTPS)). In some examples, each trust protocol interface (210) provides a communication connection between a respective transaction management system (208) and the trust protocol layer (206). More particularly, each trust protocol interface (210) allows the respective entity to perform transactions registered in a consortium trust protocol system (212) of the trust protocol layer (206). In some examples, communication between a trusted protocol interface (210), and the trusted protocol layer (206) is conducted using remote procedure calls (RPCs). In some examples, the trusted protocol interfaces (210) "host" trusted protocol nodes for the respective transaction management systems (208). For example, trust protocol interfaces (210) provide the application programming interface (API) for accessing the consortium trust protocol system (212).
    [0032] As described here, the consortium trust protocol system (212) is provided as a peer-to-peer network including a plurality of nodes (214) that immutably record information in a trust protocol (216) . Although a single trust protocol (216) is schematically represented, multiple copies of the trust protocol (216) are provided, and are maintained throughout the consortium trust protocol system (212). For example, each node (214) stores a copy of the trust protocol (216). In some embodiments, the trust protocol (216) stores information associated with transactions that are performed between two or more entities participating in the consortium trust protocol system (212).
    [0033] Figure 3 illustrates an example of consensus process (300) based on PBFT according to embodiments of the present invention. At a high level, the sample consensus process (300) is performed by a client node (node c (302)), a leader node (node 1 (304)), and a plurality of backup nodes (node 2 ( 306), node 3 (308), and node 4 (310) of a trusted protocol network. The consensus algorithm used by the trusted protocol network is assumed to be PBFT. A PBFT system may include three phases. Examples of phases may include, without limitation, pre-prepare (312), prepare (314) and commit (316). In the example described, node 4 (310) is disconnected or otherwise unavailable during the three phases of a round of consensus identified by a sequence number represented by the variable seq. After node 4 (310) is retrieved, it can request synchronization (318) with other nodes to look for lost consensus messages to ensure consensus security and liveliness PBFT. For faster synchronization, each consensus node can use its private key to digitally sign the consensus message it sends. As such, each consensus message contains a digital signature from its sending node. Even if the sending node is disconnected, or otherwise unavailable, a receiving node can safely forward the consensus message to ensure network liveliness. Details of the example process (300) are further discussed in the following description of Figure 3.
    [0034] In some embodiments, the client node (302) may send a request to add one or more transactions to the trust protocol. In some cases, the request also includes a seq variable that indicates the current consensus round. For example, if the trust protocol is in a third round of consensus, the seq variable will be equal to 3.
    [0035] After receiving one or more requests to add one or more operations to the trust protocol from the client node (302), and/or other nodes, node 1 (leader node) (304) can generate a pre-digitally signed message. -prepared (pp1). Briefly, referring to Figure 4, Figure 4 illustrates an example structure (400) of a PBFT-based consensus message in accordance with embodiments of the present invention. As shown in Figure 4, a pre-prepared message (402) may include display, digest (digest) value, transaction, timestamp, and seq. The display variable can indicate the display change number v. Changing the display in PBFT can provide liveliness, allowing PBFT to progress when the leader node fails. View changes can be triggered by timeouts that prevent backup nodes from waiting indefinitely for requests to be executed. A backup node can start a timer when it receives a request and the timer is not running. It can stop the timer when it is no longer waiting to execute the request. However, the backup node can restart the timer if at that time it is waiting to execute other requests. If the backup node timer expires on display, the backup node can initiate a display change to move the system to display v+1.
    [0036] The transaction can be the client node's request message to add transactions to the trust protocol. Scatter value can be the message digest. Timestamp can be used to ensure that each client request is executed once. Timestamps can be requested so that later requests have larger timestamps than earlier ones. For example, the timestamp might be the value of the client's local clock when the request is issued. Seq can indicate the consensus round of the message. In some embodiments, a digital signature (404) can be added to the prep message (402) using a leader node private key. In some embodiments, the consensus message, such as the pre-preparation message (402), may be stored in a node that accepts the message until a stable checkpoint is reached. A checkpoint can be the state produced by executing a request, and a checkpoint with a proof can be referred to as a stable checkpoint.
    [0037] Referring again to Figure 3, after generating the digitally signed prep message pp1, the lead node can multi-broadcast the message to the backup nodes, node 2 (306), node 3 (308) and node 4 (310).
    [0038] After node 2 (306) and node 3 (308) accept the pre-preparation message pp1, they can enter the preparation phase (314). At this point, node 4 (310) is disconnected from the trusted protocol network, or otherwise unavailable. As such, it cannot receive pp1, generate prepared message, or perform multicast. The pre-staging and staging phases can be used to request requests submitted in the same view, even when the lead node, which proposes requesting requests, is failing.
    [0039] In the prepare phase (314), node 2 (306) can multibroadcast its prepare message p2 to other nodes, and add both pp1 and p2 to its register Similarly, node 3 (308) can multicast broadcast your p3 readiness message to other nodes, and add the pp1 and p3 to your log. Referring again to Figure 4, the setup message (406) may include display, scatter value, and seq. A digital signature (408) can be added to the prepare message (406).
    [0040] Referring again to Figure 3, node 2 (306) and node 3 (308) can digitally sign p2 and p3, respectively, using their private keys. In some embodiments, a node may enter the confirm phase (316) if it receives consensus messages 2f that have the same scatter value as its own scatter value, where f is a maximum number of bad nodes that is tolerable by the PBFT-based trust protocol. The value f can be calculated as the largest integer less than or equal to (n -1)/3, where n is the total number of nodes. In the consensus process example (300), since the total number of nodes is 4, f = 1.
    [0041] Assuming all received scatter values are the same scatter values of the node itself, after receiving p2 and p3, node 1 (304) has 2f scatter values, and can generate and multi-scatter a compromise c1, and add p2, p3, and c1 to your register. Likewise, node 2 (306) can generate and multi-broadcast a c2 commitment after receiving pp1 and p3 and add p3 and c2 to its record Node 3 (308) can generate and multi-broadcast a c3 commitment after receive pp1 and p2 and add p2 and c3 to your record. As such, after a consensus node receives a digitally signed consensus message from another node, the consensus message and digital signature can be stored locally on the receiving node. Digitally signed consensus messages can be sorted based on the corresponding seq value to ensure the correct order of messages.
    [0042] Referring again to Figure 4, the compromise message (410) can include display, scatter value and seq. A digital signature (412) can be added to the commitment message (410).
    [0043] Referring again to Figure 3, assuming that node 4 (310) recovers, and reconnects to the trusted protocol network, it can start the synchronization phase (318) to fetch the messages missing during your unconnected time. In some embodiments, to prevent a node 4 timer (310) from expiring on display, and start a display change, a fetch timer can be set to run before the display times out.
    [0044] In response to a search timer running out, node 4 (310) may determine one or more consensus nodes that have consensus messages that node 4 (310) has missed. Node 4 (310) can randomly select among one or more consensus nodes to send a search request based on a gossip algorithm. The fetch request can include the node's seq number, and the types of consensus messages that are missing.
    [0045] In the consensus process example (300), the types of consensus messages that are missing include pre-prepared, prepared, and committed. As such, the fetch request can have a form of seq <pp, p, c>. In some examples, node 4 (310) randomly selects node 3 (308) based on the gossip algorithm to fetch the missing consensus messages. Node 3 (308) recorded pp1, p2, p3, c1, c2 and c3 in the seq consensus round. Because all registered messages include digital signatures from the sending nodes, their authenticity can be verified using public keys from the corresponding sending nodes. Once node 3 (308) has recorded three consensus messages c1, c2 and c3, which are greater than or equal to 2f + 1, it can provide the digitally signed messages pp1, p2, p3, c1, c2, c3 to node 4 (310). In some cases, if the node receiving the fetch request has logged fewer than 2f + 1 consensus messages, the requesting node may fetch from other nodes in the system until at least 2f + 1 consensus messages are obtained. In the example process (300), node 4 (310) can fetch all consensus messages as long as any of node 1 (304), node 2 (306), and node 3 (308) are connected to the trusted protocol network. Therefore, the recovered node may only need to run the sync once to fetch the missing messages. As such, network resources can be saved and system efficiency can be improved.
    [0046] Figure 5 represents an example process (500) that can be performed according to embodiments of the present invention. For clarity of presentation, the description that follows generally illustrates example process 500 in the context of the other figures in this description. However, it will be understood that example process 500 may be executed, for example, by any system, environment, software and hardware, or a combination of systems, environments, software and hardware, as appropriate. In some embodiments, several steps of the example process 500 may be performed in parallel, in combination, in loops, or in any order.
    [0047] In (502), a backup node of a PBFT system reconnected to a PBFT-based trust protocol network sets a timer that runs out before a display change times out. At (504), the backup node sends another consensus node a request for one or more consensus messages missed by the backup node in response to the timer running out. In some embodiments, the request includes a sequence number that indicates a number of consensus rounds. In some embodiments, the one or more consensus messages include one or more pre-prepared messages, prepared messages, and compromise messages missed by the first consensus node.
    [0048] In (506), the backup node receives, from the consensus node, one or more consensus messages, each one digitally signed by a private key from a corresponding consensus node that generates the respective one or more consensus messages. In some embodiments, one or more consensus messages include one or more pre-prepared messages, prepared messages, and compromise messages missed by the first consensus node. In some embodiments, one or more consensus messages are stored on one or more consensus nodes where they are generated or stored, until a stable checkpoint is reached.
    [0049] In (508), the backup node determines that a block of transactions is valid, if the amount of compromise messages included in the one or more consensus messages received is greater than or equal to 2f + 1, where f is a maximum number of faulty nodes that is tolerable by the PBFT-based trust protocol. In some embodiments, the backup node further receives one or more sequence numbers corresponding to one or more consensus messages. Each sequence number indicates a number of consensus rounds associated with a corresponding consensus message.
    [0050] In some embodiments, the backup node still sends the transaction block to a trusted protocol, and a state database, if the transaction block is determined to be valid. In some embodiments, the backup node further sends to a third consensus node other than the consensus node and the backup node a request for a second one or more consensus messages lost by the consensus node in response to the time if running out and if the transaction block is determined to be invalid. The backup node receives, from the third consensus node, the second one or more consensus messages, each digitally signed by a private key from a corresponding consensus node, which generates the second one or more consensus messages. The backup node then determines that the transaction block is valid if the number of compromise messages included in one or more consensus messages and the second one or more consensus messages are greater than or equal to 2f + 1.
    [0051] The embodiments of the invention described in this specification can be implemented in order to realize particular advantages or technical effects. For example, embodiments of the present invention allow consensus nodes of a consensus trust protocol to send digitally signed consensus messages with a sequence number that identifies the consensus round of the corresponding message. Digitally signed consensus messages can be trusted by a backup node to be secure and the message origins can be verified. As such, the data security and privacy of the consortium trust protocol can be improved. Also, if the backup node is recovered from a disconnect, it can synchronize with other nodes by fetching lost messages from another random consensus node instead of broadcasting a fetching request to the entire network. Because messages obtained from another consensus node are digitally signed by the sender node, the message sources can be trusted and the backup node can retrieve all lost messages from one node through a synchronization. . As such, the synchronization or consensus complexity can be reduced to O(1) under ideal conditions, compared to O(n) based on the standard multicast method in PBFT. Correspondingly, computing and network resources can be saved, and the efficiency of the PBFT system can be improved.
    [0052] The described methodology can ensure the efficient use of computer resources (eg processing cycles, bandwidth and memory usage), through efficient updating of the trust protocol. Account operations can be done faster and more securely through simpler consensus processes.
    [0053] Embodiments and operations described in this specification may be implemented in digital electronic circuits, or in computer software, firmware or hardware, including the structures disclosed in this specification or in combinations of one or more of them. Operations may be implemented as operations performed by a data processing apparatus on data stored on one or more computer-readable storage devices or received from other sources. A computing device (120), computer or data processing apparatus may encompass apparatus, devices and machines for processing data, including, for example, a programmable processor, a computer, a system on a chip or several, or combinations, of precedents. The apparatus may include special purpose logic circuits, for example a central processing unit (CPU), an FPGA (programmable port network) or an ASIC (Application Specific Integrated Circuit). The apparatus may also include code that creates an execution environment for the computer program in question, e.g. code that constitutes processor firmware, a protocol stack, a database management system, an operating system (e.g. , an operating system, or a combination of operating systems), a cross-platform runtime environment, a virtual machine, or a combination of one or more of them. The appliance and execution environment can realize many different computing model infrastructures, such as web services, distributed computing, and grid computing infrastructures.
    [0054] A computer program (also known, for example, as a program, software, software application, software module, software unit, script, or code) can be written in any form of programming language, including compiled languages. or interpreted, declarative or procedural languages, and may be implemented in any form, including as a stand-alone program or as a module, component, subroutine, object, or other unit suitable for use in a computing environment. A program can be stored in a part of a file that contains other programs or data (for example, one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files ( for example, files that store one or more modules, subprograms, or parts of code). A computer program can run on one computer or on multiple computers located at one site or distributed across multiple sites and interconnected by a communication network.
    [0055] Processors for executing a computer program include, by way of example, general and special purpose microprocessors, and any one or more processors of any type of digital computer. Generally, a processor will receive instructions and data from either read-only memory or random access memory, or both. The essential elements of a computer are a processor to perform actions according to instructions and one or more memory devices to store instructions and data. Generally, a computer will also include, or be operationally coupled to, receive data or transfer data to, or both, one or more mass storage devices for storing data. A computer can be embedded in another device, for example, a mobile device, a personal digital assistant (PDA), a game console, a Global Positioning System (GPS) receiver, or a portable storage device. Devices suitable for storing computer program instructions and data include non-volatile memory, media and memory devices, including, by way of example, semiconductor memory devices, magnetic disks, and magneto-optical disks. The processor and memory may be supplemented by, or incorporated into, special-purpose logic circuits.
    [0056] Mobile devices may include microphones, user equipment (UE), cell phones (e.g. smartphones), tablets, wearable devices (e.g. smart watches and smart glasses), devices implemented in the human body (e.g. biosensors, cochlear implants) or other types of mobile devices. Mobile devices can communicate wirelessly (for example, using radio frequency (RF) signals) to various communication networks (described below). Mobile devices can include sensors to determine the characteristics of the mobile device's current environment. Sensors can include cameras, microphones, proximity sensors, GPS sensors, motion sensors, accelerometers, ambient light sensors, humidity sensors, gyroscopes, compasses, barometers, fingerprint sensors, facial recognition systems, RF sensors ( for example, Wi-Fi and cellular radios), thermal sensors or other types of sensors. For example, cameras may include a forward-facing or backward-facing camera with moving or fixed lenses, a flash, an image sensor, and an image processor. The camera can be a megapixel camera capable of capturing details for facial and/or iris recognition. The camera, together with a data processor and authentication information stored in memory or accessed remotely, can form a facial recognition system. The facial recognition system or one or more sensors, for example microphones, motion sensors, accelerometers, GPS sensors or RF sensors can be used for user authentication.
    [0057] To provide interaction with a user, the embodiments can be implemented on a computer that has a display device and an input device, for example, a liquid crystal display (LCD) or diode display screen. organic light emitting (OLED)/virtual reality (VR)/augmented reality (AR) to display information to the user and a touch screen, keyboard and pointing device by which the user can provide input to the computer. Other types of devices may also be used to provide interaction with a user; for example, feedback provided to the user may be any form of sensory feedback, eg visual feedback, auditory feedback or haptic feedback; and user input can be received in any form, including acoustic, speech, or tactile input. In addition, a computer can interact with a user by sending documents to and receiving documents from a device that is used by the user; for example, sending web pages to a web browser on a user's client device in response to requests received from the web browser.
    [0058] The embodiments may be implemented using computing devices interconnected by any form or means of wired or wireless digital data communication (or combination thereof), for example, a communication network. Examples of interconnected devices are a client and a server that are usually remote from each other that normally interact over a communication network. A client, for example a mobile device, can carry out transactions on itself, with a server or through a server, for example, carrying out transactions of purchase, sale, payment, delivery, shipment or loan, or authorizing the same. Such transactions may be real-time, so that an action and a response are temporarily close together; for example, an individual perceives the action and response occurring substantially simultaneously, the time difference for a response following the individual's action is less than 1 millisecond (ms) or less than 1 second (s), or the response is without delay intentional, taking into account system processing limitations.
    [0059] Examples of communication networks include a local area network (LAN), a radio access network (RAN), a metropolitan area network (MAN) and a wide area network (WAN). The communication network may include all or part of the Internet, another communication network, or a combination of communication networks. Information may be transmitted over the communication network in accordance with various protocols and standards, including Long Term Evolution (LTE), 5G, IEEE 802, Internet Protocol (IP) or other protocols or combinations of protocols. The communication network can transmit voice, video, biometric or authentication data, or other information between connected computing devices.
    [0060] The features described as separate embodiments may be implemented, in combination, in a single implementation, while the features described as a single implementation may be implemented in multiple embodiments, separately or in any suitable sub-combination. The operations described and claimed in a specific order should not be understood as requiring that the specific order, nor that all illustrated operations be performed (some operations may be optional). As appropriate, multitasking or parallel processing (or a combination of multitasking and parallel processing) can be performed.
    权利要求:
    Claims (12)
    [0001]
    1. COMPUTER IMPLEMENTED METHOD (500) TO FACILITATE A CONSENSUS PROCESS (300) IN A RELIABLE PROTOCOL NETWORK (102, 212) BASED ON PRACTICAL BYZANTINE FAILURE TOLERANCE, characterized by comprising: defining, through a first node consensus (304), a display timer for initiating, after a display timer timeout, a display change of a current display; setting (502), via the first consensus node (304), a search timer that runs out before the display timer; determining, by means of the first consensus node (304) and in response to the search timer running out, whether one or more consensus messages (p2) are missing by the first consensus node (304); and if one or more consensus messages (p2) are determined to be missing by the first consensus node (304): send (504), through the first consensus node (304) and only to a second consensus node (306) ), a request (pp1) for the one or more missing consensus messages (p2) through the first consensus node (304); receive (506), via the first consensus node (304) from the second consensus node (306), one or more consensus messages (p2), each digitally signed (404) by a node's private key corresponding consensus message that generates the respective one or more consensus messages (p2); and determining (508), via the first consensus node (304), that a block of transactions is valid, if an amount of commitment messages included in the one or more consensus messages (p2) received is greater than or equal to 2f + 1, where f is a maximum number of bad nodes that is tolerable by a trust protocol (104) based on practical Byzantine fault tolerance.
    [0002]
    2. COMPUTER IMPLEMENTED METHOD (500), according to claim 1, characterized in that the request (pp1) includes a sequence number that indicates a number of a consensus round.
    [0003]
    3. COMPUTER IMPLEMENTED METHOD (500), according to claim 1, characterized in that one or more consensus messages (p2) include one or more pre-prepared messages, prepared messages and compromise messages missing by the first consensus node ( 304).
    [0004]
    4. COMPUTER IMPLEMENTED METHOD (500), according to claim 1, characterized in that one or more consensus messages (p2) are stored in one or more consensus nodes (304, 306, 308, 310) in which they are generated or stored, until a stable checkpoint is reached.
    [0005]
    5. COMPUTER IMPLEMENTED METHOD (500), according to claim 1, characterized in that it further comprises receiving one or more sequence numbers corresponding to one or more consensus messages (p2), wherein each sequence number indicates a number of a consensus round associated with a corresponding consensus message (p2).
    [0006]
    6. METHOD IMPLEMENTED BY COMPUTER (500), according to claim 1, characterized in that it further comprises sending the block of transactions to a trusted protocol (104) and a status database, if the block of transactions is determined as valid.
    [0007]
    7. COMPUTER IMPLEMENTED METHOD (500), according to claim 1, further comprising: determining, through the first consensus node (304) and in response to the search timer running out, whether a second or more messages consensus (p2, p3, c2) are missing by the first consensus node (304); determine whether the transaction block is determined to be invalid; and if one or more second consensus messages (p2, p3, c2) are determined to be missing by the first consensus node (304) or if the transaction block is determined to be invalid: send, via the first consensus node (304) to a third consensus node (308), the request (pp1) for the second one or more missing consensus messages (p2, p3, c2) via the second consensus node (306); receive, via the first consensus node (304) from the third consensus node (308), the second one or more consensus messages (p2, p3, c2), each digitally signed (404) by a private key of a corresponding consensus node (306, 308) which generates the respective second one or more consensus messages (p2, p3, c2); and determining, by means of the first consensus node (304), that the transaction block is valid, if a number of the commitment messages are included in the one or more consensus messages (p2, p3, c2) and the second one or more more consensus messages (p2, p3, c2) are greater than or equal to 2f + 1.
    [0008]
    8. COMPUTER IMPLEMENTED METHOD (500), according to claim 7, characterized in that the third consensus node (308) is different from the first consensus node (304) and the second consensus node (306).
    [0009]
    9. COMPUTER IMPLEMENTED METHOD (500), according to any one of claims 7 to 8, characterized in that it further comprises randomly selecting, by the first consensus node (304), the third consensus node (308) from a plurality of backup nodes (306, 308, 310) of the trusted protocol network (102, 212).
    [0010]
    10. COMPUTER IMPLEMENTED METHOD (500), according to any one of claims 1 to 9, characterized in that it further comprises randomly selecting, by the first consensus node (304), the second consensus node (306) from a plurality of backup nodes (306, 308, 310) of the trusted protocol network (102, 212).
    [0011]
    11. NON-TRANSITORY, COMPUTER-READABLE STORAGE, characterized by being coupled to one or more processors and having instructions stored therein, which, when executed by the one or more processors, cause the one or more processors to perform operations in accordance with the method (500) as defined in any one of claims 1 to 10.
    [0012]
    12. SYSTEM (106, 108), characterized in that it comprises: a computing device (120); and a computer readable storage device coupled to the computing device (120) and having instructions stored therein which, when executed by the computing device (120), cause the computing device (120) to perform operations in accordance with the method (500) as defined in any one of claims 1 to 10.
    类似技术:
    公开号 | 公开日 | 专利标题
    BR112019008172B1|2022-01-25|Computer-implemented method of facilitating a consensus process in a trusted protocol network based on practical Byzantine fault tolerance, computer-readable non-transient storage medium, and system
    KR102237219B1|2021-04-08|Achieving consensus among network nodes in a distributed system
    AU2019248542B2|2020-11-05|Cross-blockchain authentication method and apparatus
    KR20200074912A|2020-06-25|Change of primary node in distributed system
    AU2019248525B2|2021-08-12|Cross-blockchain authentication method, apparatus, and electronic device
    JP6810259B2|2021-01-06|Manage private transactions on the blockchain network based on workflow
    US20200403801A1|2020-12-24|Methods and systems for automatic blockchain deployment based on cloud platform
    US11108571B2|2021-08-31|Managing communications among consensus nodes and client nodes
    JP2021518962A|2021-08-05|Asynchronous processing of blockchain blocks
    Charapko et al.2018|Bridging paxos and blockchain consensus
    BR112019008140B1|2021-11-30|COMPUTER-IMPLEMENTED METHOD, COMPUTER-READABLE STORAGE MEDIA AND SYSTEM FOR IMPLEMENTING A METHOD
    同族专利:
    公开号 | 公开日
    PH12019500902B1|2019-12-02|
    BR112019008172A2|2019-09-10|
    AU2018347187B2|2020-09-03|
    PL3542514T3|2021-08-30|
    US20190251077A1|2019-08-15|
    KR102193549B1|2020-12-23|
    JP2020504351A|2020-02-06|
    PH12019500902A1|2019-12-02|
    RU2724181C1|2020-06-22|
    MX2019004657A|2019-08-12|
    EP3542514A4|2019-11-27|
    JP6727630B2|2020-07-22|
    WO2019072263A3|2019-08-29|
    AU2018347187A1|2020-05-21|
    CA3041463A1|2019-04-18|
    ZA201902555B|2020-01-29|
    EP3836512A1|2021-06-16|
    WO2019072263A2|2019-04-18|
    EP3542514B1|2021-02-17|
    US11036721B2|2021-06-15|
    KR20200054127A|2020-05-19|
    CN110115001A|2019-08-09|
    EP3542514A2|2019-09-25|
    US20210026839A1|2021-01-28|
    US10803052B2|2020-10-13|
    US20210303550A1|2021-09-30|
    ES2867423T3|2021-10-20|
    CA3041463C|2020-08-25|
    SG11201903581WA|2019-05-30|
    引用文献:
    公开号 | 申请日 | 公开日 | 申请人 | 专利标题
    US7392391B2|2001-11-01|2008-06-24|International Business Machines Corporation|System and method for secure configuration of sensitive web services|
    US8745401B1|2010-11-12|2014-06-03|Google Inc.|Authorizing actions performed by an online service provider|
    KR101757245B1|2015-07-28|2017-07-13|한국과학기술원|Pickering emulsion and method for preparation thereof|
    JP6767007B2|2015-11-20|2020-10-14|株式会社写真化学|Stereolithography equipment|
    KR20170137388A|2016-06-03|2017-12-13| 블록체인오에스|A method for ensuring integrity by using a blockchain technology|
    CN106447311B|2016-09-26|2019-11-08|北京天德科技有限公司|A kind of block chain of Byzantine failure tolerance algorithms of four communications builds block method|
    EP3281115B1|2016-10-04|2019-06-19|Nec Corporation|Method and system for byzantine fault-tolerance replicating of data on a plurality of servers|
    EP3394756A1|2016-11-25|2018-10-31|NEC Laboratories Europe GmbH|Method and system for byzantine fault - tolerance replicating of data|
    CN107368507B|2017-03-28|2020-03-27|创新先进技术有限公司|Block chain-based consensus method and device|
    CN107124403A|2017-04-14|2017-09-01|朱清明|The generation method and computing device of common recognition block in block chain|
    CN107301600B|2017-06-23|2021-07-20|北京天德科技有限公司|Core construction method of block chain Internet model for cross-chain transaction|
    CN107579848B|2017-08-30|2020-08-25|上海保险交易所股份有限公司|Method for dynamically changing consensus node in practical Byzantine fault-tolerant consensus mechanism|
    RU181439U1|2018-04-06|2018-07-13|Оксана Валерьевна Кириченко|Decentralized technology platform for storing and exchanging transaction data in a distributed computing network|
    BR112019008172B1|2018-11-07|2022-01-25|Advanced New Technologies Co., Ltd|Computer-implemented method of facilitating a consensus process in a trusted protocol network based on practical Byzantine fault tolerance, computer-readable non-transient storage medium, and system|CN110445619B|2017-03-30|2020-10-16|腾讯科技（深圳）有限公司|Block chain system, message processing method and storage medium|
    BR112019008172B1|2018-11-07|2022-01-25|Advanced New Technologies Co., Ltd|Computer-implemented method of facilitating a consensus process in a trusted protocol network based on practical Byzantine fault tolerance, computer-readable non-transient storage medium, and system|
    KR102170347B1|2019-03-18|2020-10-28|알리바바 그룹 홀딩 리미티드|System and method for terminating view change protocol|
    EP3593249B1|2019-03-18|2021-06-23|Advanced New Technologies Co., Ltd.|System and method for ending view change protocol|
    WO2019137565A2|2019-04-26|2019-07-18|Alibaba Group Holding Limited|Distributed key management for trusted execution environments|
    CN110166295B|2019-05-23|2021-07-30|杭州趣链科技有限公司|Method for judging whether network topology supports Byzantine fault tolerance or not|
    US11050822B2|2019-06-05|2021-06-29|International Business Machines Corporation|Secure data dissemination|
    SE544149C2|2019-06-25|2022-01-11|Coined Invest Pool Company Ab|Method and system for performing electronic transactions|
    CN110636113A|2019-08-23|2019-12-31|上海电力大学|Byzantine fault-tolerant consensus method, system, device and storage medium for blockchains|
    CN110727731B|2019-09-05|2021-12-21|创新先进技术有限公司|Method for adding node in block chain network and block chain system|
    CN110730204A|2019-09-05|2020-01-24|阿里巴巴集团控股有限公司|Method for deleting nodes in block chain network and block chain system|
    CN110661656B|2019-09-20|2022-03-04|广东卓启投资有限责任公司|Block chain rapid consensus method and device|
    EP3908932A1|2019-10-14|2021-11-17|NEC Laboratories Europe GmbH|Topology-driven byzantine fault-tolerant consensus protocol with vote aggregation|
    CN111163148B|2019-12-24|2021-09-28|腾讯科技（深圳）有限公司|Synchronization method and related equipment for consensus state of block chain system|
    US11250021B2|2020-04-17|2022-02-15|International Business Machines Corporation|Faster view change for blockchain|
    CN111698315B|2020-06-09|2021-10-15|腾讯科技（深圳）有限公司|Data processing method and device for block and computer equipment|
    EP3957025A4|2020-07-03|2022-02-23|Alipay Hangzhou Inf Tech Co Ltd|System and method for providing privacy and security protection in blockchain-based private transactions|
    CN113888168A|2020-07-03|2022-01-04|支付宝信息技术有限公司|Consensus method of alliance chain, data verification method, device and system|
    CN112068978A|2020-08-27|2020-12-11|恒宝股份有限公司|Method for prolonging timing period of VIEW-CHANGE secondary start timer|
    CN113301149A|2021-05-24|2021-08-24|山东大学|Trusted software defined network construction method based on block chain|
    CN113316177A|2021-06-01|2021-08-27|山东大学|Decision communication system and decision communication method for intelligent group|
    CN113922971A|2021-06-02|2022-01-11|支付宝信息技术有限公司|Cross-chain interaction method and device|
    CN113259120B|2021-06-02|2021-09-24|支付宝信息技术有限公司|Method for synchronizing node information lists|
    CN113328920B|2021-08-04|2021-10-29|成都飞机工业（集团）有限责任公司|Method for collecting and storing equipment data|
    CN113541968B|2021-09-16|2021-11-26|中国信息通信研究院|Consensus method, device and block chain system|
    CN113630257B|2021-10-09|2022-01-04|支付宝信息技术有限公司|Consensus method, block chain system and consensus node|
    法律状态:
    2021-01-19| B25A| Requested transfer of rights approved|Owner name: ADVANTAGEOUS NEW TECHNOLOGIES CO., LTD. (KY) |
    2021-02-09| B25A| Requested transfer of rights approved|Owner name: ADVANCED NEW TECHNOLOGIES CO., LTD. (KY) |
    2021-10-05| B350| Update of information on the portal [chapter 15.35 patent gazette]|
    2021-12-14| B09A| Decision: intention to grant [chapter 9.1 patent gazette]|
    2021-12-14| B15K| Others concerning applications: alteration of classification|Free format text: A CLASSIFICACAO ANTERIOR ERA: H04L 29/06 Ipc: G06F 11/07 (2006.01), G06F 11/18 (2006.01), H04L 2 |
    2022-01-25| B16A| Patent or certificate of addition of invention granted [chapter 16.1 patent gazette]|Free format text: PRAZO DE VALIDADE: 20 (VINTE) ANOS CONTADOS A PARTIR DE 07/11/2018, OBSERVADAS AS CONDICOES LEGAIS. |
    优先权:
    申请号 | 申请日 | 专利标题
    PCT/CN2018/114334|WO2019072263A2|2018-11-07|2018-11-07|Facilitating practical byzantine fault tolerance blockchain consensus and node synchronization|
    [返回顶部]